REMARKS 

Overview of the Office Action 

Claims 1-4 and 9-14 have been rejected under 35 U.S.C. §103(a) as unpatentable over 
U.S. Patent No. 7,320,026 ("Adamczyk"). and in view of ("RFC 3026"). 

Claims 5-8 have been objected to as depending from a rejected base claim, but would be 
allowable if rewritten in independent form including the base claim and any intervening claims. 

Status of the claims 

Claim 1 , 5, 9-1 1 , and 14 have been amended. 
Claims 1-14 are pending. 

Rejection of claims 1-4 and 9-14 under 35 U.S.C. $ 103(a) 

The Office Action states that the combination of Adamczyk and RFC 3026 teaches all of 
Applicants' recited elements. Applicants disagree. 

Independent claim 1 recites "a prior test of the validity of the destination telephone 
number (NTEL) of the request (R) is executed automatically and locally to the requesting 
machine (H) relative to a telephone number database (BD) local to the requesting machine (H) in 
order to forward the request (R) from the requesting machine (H) to the domain name server only 
if its destination telephone number (NTEL) passes said test", which Adamczyk and RFC 3026, 
whether taken alone or in combination, fail to teach or suggest. 

Adamczyk discloses a method for transferring voice messages between proprietary voice 
message systems over the Internet (see col. 1, lines 56-64 and Fig. 3 of Adamczyk). According 
to Adamczyk, a requesting machine (user's platform 308) sends one or more requests for 
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subscriber address information to a DNS (ENUM server 318) wherein the request identifies a 
telephone number for the subscriber (in ENUM format) (see col.7, lines 1-8 of Adamczyk). In 
return, the DNS provides the requesting machine with the IP address of the server LDAP (and 
database) 322 associated with the provided phone number (see col.7, lines 9-15 of Adamczyk). 

Once the IP address of the appropriate server/database 322 of Adamczyk has been 
identified, the requesting machine can obtain from the server/database 322 the specific domain 
name address and routing information necessary to forward the voice message to the destination 
subscriber (see col.7, lines 31-39 of Adamczyk). Further, it is essential that the requesting 
machine of Adamczyk sends its request to the DNS prior to communicating with the database 
322 in order to obtain the IP address of the database 322 (see col.7, lines 3-8 of Adamczyk). 

The Examiner appears to conclude that the LDAP server/database 322 of Adamczyk 
corresponds to Applicants' recited database (BD) that is local to the requesting machine. 
Applicants' disagree. 

The Examiner asserts that the platform 308 of Adamczyk corresponds to Applicants' 
recited requesting machine (H). As shown in Fig. 3 of Adamczyk, however, the LDAP database 
322 is not local to the platform 308. Instead, the database 322 of Adamczyk is accessed 
remotely over an internet connection (see Fig. 3 of Adamczyk). Further, according to Adamczyk 
"the LDAP server 322 is associated with the platform 310" (see col. 7, lines 9-10 of Adamczyk). 
Thus, the LDAP server/database 322 is not local to the platform 308 (requesting machine (H)) 
and does not correspond to Applicants' recited database (BD) that is local to the requesting 
machine. 

In contrast to the configuration in Adamczyk, Applicants' recited database (BD) is local to 
the requesting machine (H) (see Fig 1 of Applicants' published specification). This results in 
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significant improvements in terms of reduced communications/signaling traffic (e.g., over the 
Internet or the like) and processing overhead. 

Additionally, as described above, Adamczyk teaches that the DNS 3 1 8, in response to a 
request from the platform 308, returns the IP address of the appropriate server LDAP (and 
database) 322. Accordingly, Adamczyk teaches that the request must always be sent to the DNS 
prior to any communication with database 322. This is because it is the DNS 3 1 8 that identifies 
which server (and database) is associated with the destination number. 

Consequently, Adamczyk teaches away from the step of performing locally a test of 
validity of the destination telephone number prior to sending the request to the DNS. A person 
skilled in the art would immediately understand that it is essential in Adamczyk that the 
requesting machine first sends its request to the DNS (whether or not the request is valid) in 
order to gain access to the appropriate database 322. Hence, there is no need for, or reason to 
provide, a local test of the validity of the destination telephone number prior to sending the 
request to the DNS in the system of Adamczyk. 

The Examiner concedes that Adamczyk fails to teach or suggest "a prior test of the validity 
of the destination telephone number (NTEL) of the request (R) is executed automatically and 
locally to the requesting machine (H) relative to a telephone number database (BD) local to the 
requesting machine (H) in order to forward the request (R) from the requesting machine (H) to 
the domain name server only if its destination telephone number (NTEL) passes said test", as 
recited in Applicants' claim 1. 

The Examiner cites RFC 3026 as teaching an entity (to which E.164 test codes have been 
assigned) that is responsible for providing appropriate assignment information to DNS 
administrators. The Examiner asserts that this teaching implies that prior to any type of 
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information being routed, there must be a check capability to verify the validity of the destination 
telephone number, including format, country code, and domain name. The Examiner further 
asserts that it would have been obvious to incorporate these teachings of RFC 3026 into the 
teachings of Adamczyk for the purpose of clearly defining the ENUM format including the 
country code and verifying or testing this format prior to actual call processing. Applicants 
disagree. 

RFC 3026 discloses a method for administering and maintaining the E.164 based resources 
in the DNS as related to the ENUM protocol (see Abstract). RFC 3026 also discloses that the 
ITU (International Telecommunication Union) has the responsibility of providing assignment 
information to DNS administrators. According to RFC 3026, the list of spare codes should be 
provided to the DNS administrators. Further, "test codes" are also assigned to various entities. 
These entities are considered as being responsible "for providing any appropriate assignment 
information" to DNS administrators (see page 2, second bullet of RFC 3026). 

According to RFC 2602 (June 1999), "test codes" are addresses specifically reserved for 
testing purposes within DNS. In others words, the test codes are meant to be used for internal 
tests of the local DNS code and/or configuration. Accordingly, the test codes of RFC 3026 have 
nothing to do with testing the validity of specific destination telephone numbers, as recited in 
Applicants' claim 1. 

Further, although RFC 3026 mentions that assignment information should be provided to 
the DNS administrators, no further details regarding this information are provided. Therefore, 
one skilled in the art would not, and could not, conclude that RFC 3026 teaches that prior to any 
type of information being routed to a requestor, there should be a check to verify the validity of 
the destination telephone number, including format, country code, and domain name. 
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RFC 3026, therefore, fails to teach or suggest "a prior test of the validity of the destination 
telephone number (NTEL) of the request (R) is executed automatically and locally to the 
requesting machine (H) relative to a telephone number database (BD) local to the requesting 
machine (H) in order to forward the request (R) from the requesting machine (H) to the domain 
name server only if its destination telephone number (NTEL) passes said test", as recited in 
Applicants' claim 1. 

Additionally, even if one skilled in the art were to somehow conclude that RFC 3026 does 
teach Applicants' above-described feature, the person of skill would not consider or be motivated 
to combine such teaching with the teachings of Adamczyk because, as discussed above, 
Adamczyk teaches away from the step of performing locally a test of validity of the destination 
telephone number prior to sending the request to the DNS. Instead, Adamczyk explicitly 
teaches that the requesting machine must first send the request to the DNS (whether or not the 
request is valid) in order to gain access to the appropriate database. Hence, there is no need for, 
or reason to provide, a local test of the validity of the destination telephone number prior to 
sending the request to the DNS in the system of Adamczyk. 

Adamczyk and RFC 3026, therefore, whether taken alone or in combination, fail to teach 
or suggest "a prior test of the validity of the destination telephone number (NTEL) of the request 
(R) is executed automatically and locally to the requesting machine (H) relative to a telephone 
number database (BD) local to the requesting machine (H) in order to forward the request (R) 
from the requesting machine (H) to the domain name server only if its destination telephone 
number (NTEL) passes said test", as recited in Applicants' claim 1. Accordingly, Applicants 
claim 1 is deemed to be patentable over Adamczyk and RFC 3026 under 35 U.S.C. §103(a). 
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Independent claims 9 and 12-14 recite limitations similar to independent claim 1 and are, 
therefore, deemed to be patentably distinct over Adamczyk and RFC 3026 for at least those 
reasons discussed above with respect to independent claim 1. 

Claims 2-4 and 10-11, which depend from independent claims 1 and 9, incorporate all of 
the limitations of the corresponding independent claim and are, therefore, deemed to be 
patentably distinct over Adamczyk and RFC 3026 for at least those reasons discussed above with 
respect to independent claims 1 and 9. 



In view of the foregoing, Applicants respectfully request reconsideration, withdrawal of 
the rejections, and allowance of all of the now-pending claims. 

Should the Examiner have any comments, questions, suggestions, or objections, the 
Examiner is respectfully requested to telephone the undersigned to facilitate a resolution of any 
outstanding issues. 

It is believed that no fees or charges are required at this time in connection with the 
present application. However, if any fees or charges are required at this time, they may be 
charged to our Patent and Trademark Office Deposit Account No. 03-2412. 



Conclusion 
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